Add method to MovingWindow that waits for a number of samples - #387

I think this one should probably be a read-only public attribute. Also for attributes it's better to use nouns instead of verbs (and it's missing the type), for example:

Plus

    @property
    def received_samples_count(self) -> int
        return self._received_samples_count

These two really look like they should be private. Same about names (and missing types):

If you never call self.wait_for_samples_event.clear() it will always fire immediately in .wait()

I recommend using nouns for non-boolean attributes:

So the text here is for debugging purposes only, right @shsms?

I'd suggest using a shorter string for that and using the long string as documentation for the variable:

I guess once a MW was stopped there is no way to start it again, right? Otherwise the sender should probably be created in the constructor instead to avoid leaking sender objects.

Since it's free and even when the user should know it beforehand anyway, we could also send the number of samples received instead of None, maybe it could become a handy shortcut.

If I understand correctly, this indirectly enables sending the events if num_samples > 0, right? If so I would rename this method to something that makes it easier to realize that happens. What about:

@property
def is_wait_for_samples_event_enabled(self) -> bool:
    # Returns `self._wait_for_num_samples != 0`

def enable_wait_for_samples_event(self, num_samples: int) -> bool:
    # Same as above but check for `num_samples > 0`, return whether it was enabled before

def disable_wait_for_samples_event(self) -> bool:
    # Set `num_samples = 0`, return whether it was enabled before

If the above suggestion is applied, I would rename this for consistency:

We could go with something different than wait_for_samples_event as it is a bit long, but the 4 methods should use the same term IMHO.

?

There are some failures that this will not detect or detect wrongly. For example if you trigger before the samples_to_wait_for this will succeed too. If the event doesn't trigger, this test will hang forever, which might be quite annoying.

Maybe could check for the internal counter to verify it is incremented? If you also add my suggestion to return the number of samples received you could add the check here too.

Maybe you can also move the await sample_count_recv.receive() to a different task so you can check it didn't fire before you sent enough samples and that it was fired after you sent all the expected samples but without blocking the main thread if it fails?

Maybe you could also push different sample values and then check that the state of the moving window is what it would be expected after receiving all that samples, so if the even triggered before that check should also fail.